1. Field of the Invention
This invention is directed to the field of networks. More particularly, it relates to apparatus and techniques for network devices such as networks which utilize a data based link integrity protocol, e.g., In Home networks.
2. Background of Related Art
Networking, and in particular Home Networking (e.g., home phone line networking based on specifications from HomePNA™) is a new segment of the networking marketplace that is poised for rapid growth. However, achieving the goals needed to make home networking a market success is a challenging task. Nascent home networking market growth will depend on the emergence of high-speed broadband access as a catalyst as well as the availability of robust, low cost, easy to install standardized home networking equipment.
Networks may include many devices of various types (e.g., Ethernet, 802.11, HomePNA, BLUETOOTH, power line networks such as Homeplug™, etc.) and may or may not include wireless devices. Many network devices power down from time to time, depending upon the particular application. The health or presence of any particular network device is often determined using a link integrity function.
The purpose of any network link integrity function is to allow one network device to detect the health or presence of another network device. Events triggered by the receipt of a valid link integrity signal typically include, e.g., lighting an available system LED. The link integrity action is therefore very beneficial to a user, e.g., by providing a visual indication that the network is functioning properly. In a two-device network, a visual indication indicating a “good” network transitioning into an inactive state (not lit) due to one of the network devices entering a power conserving mode such as a D3 power down state is likely to lead to consumer confusion.
Initial link integrity functions utilized physically unique signaling on a wired line (e.g., Ethernet devices) to signal link integrity. However, in a growing number of network applications, link integrity is being handled in data based link integrity data packets transmitted over a communication link, instead of providing a unique electrical signal.
It is a general requirement of many such network devices to implement a link integrity function to ensure that, with high probability within some periodic interval, there is either (1) at least one link packet such as a link integrity control frame (LICF) sent to the Broadcast MAC address from the relevant station, or (2) at least one packet addressed to the Broadcast MAC address received from each of at least two other stations.
FIG. 5 shows a conventional data-based link integrity module incorporated within core memory of a network device, in accordance with the principles of the present invention.
In particular, as shown in FIG. 5, a network device 550 includes a core processor 502 (e.g., processor, microprocessor, or digital signal processor), core memory 504, a link interface 506, and a power mode control module 508 (which may alternatively be integrated within the core processor 502 and/or the core memory 504). As depicted in FIG. 5, the core memory 504 includes a driver or other implementation of a software link integrity module 510.
Using the data based link integrity techniques, a software driver is typically loaded into a processor (e.g., a core CPU) to handle link integrity functions, either in response to an external request, or to itself report its health and/or presence. The software driver technique determines whether or not a particular network device is able to receive frames from at least one other device on the network. In the absence of other traffic, the network device will periodically transmit, e.g., a Link Integrity Control Frame (LICF) to a Broadcast Media Access Control (MAC) address.
For instance, in the emerging Home Phoneline Network Alliance (HomePNA) Version 2.0 (V2) specification, link integrity is defined as a valid Ethernet packet-based approach periodically sent out in a defined frame format at a system negotiated encoding rate. Because system parameters can change as the quality of the channel changes, the encoding rate tends to be dynamic.
For instance, the Advance Configuration and Power Interface (ACPI) standard defines various power states that PC-centric devices must operate in, including a D3 cold state. In the D3 cold state, power is fully removed from the particular device at the system level. However, when power is removed, the device context is lost and thus no driver remains present.
Bound by this criteria, a link integrity function is easily performed by driver level code. However, the drivers must be maintained by the supporting network device for the link integrity function to be performed. Because of this, network devices using data based link integrity typically do not transition to a power down state.
Accordingly, link integrity is not supported in a network device which relies on data based link integrity functionality when the network device enters a D3 cold state. To support link integrity, such devices must first power up from the D3 cold state, first reinstalling the pertinent link integrity driver(s). Typically, to provide link integrity as many specifications require (e.g., HomePNA version 2.0), the D3 cold state in such devices is conventionally avoided.
The current method defined in the HomePNA V2 specification for link integrity is a packet-based approach sent at the highest priority class of service. A minimum payload encoding (PE) value is negotiated and each station is required to send out the link integrity packet with a determined packet format at this negotiated PE value.
While this conventional approach is adequate when the system is in a functional and fully operational state, problems exist during the ACPI-defined power down states. In the context of ACPI, a “fully operational state” is defined as a non-D3 power state. In the fully operational state, the device is completely active and responsive, and is expected to continuously retain all relevant context information. However, when in a D3 power state, power is fully removed from the device. Unfortunately, device context is lost when this non-powered state is entered, and thus any/all software drivers that were present will be lost. Thus, while in a non-powered or D3 state, network device context information such as data, software drivers, etc., are lost, and thus network devices in this state certainly do not decode their network address lines, causing problems with respect to conventional software based link integrity techniques. After power is returned to the network device, the operating system (OS) will be required to reinitialize the network device, and relevant drivers will be reloaded.
Network devices in a D3 type cold state will typically require a relatively long restart/restore time to return to a functional state capable of handling link integrity functions. Therefore, latency time is significant if a network device is to be woken up from a D3 type cold state to handle link integrity functions. This becomes problematic when a fully functional node in a network needs access to another device in the network that is currently in a D3 cold (i.e., un-powered) state.
There is a need for an approach that allows the provision of a link integrity function while a network device is in a D3 type cold state.